✅ Deploy Preview for expressjscom-preview ready!

Name	Link
🔨 Latest commit	e1fed96
🔍 Latest deploy log	https://app.netlify.com/sites/expressjscom-preview/deploys/67c38e103517430008f024ea
😎 Deploy Preview	https://deploy-preview-1775--expressjscom-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

Hi @ShubhamOulkar, Thanks for the PR. I was just looking at this and have some concerns.

• The menu file should not be removed like this. It seems to me that this is already essentially a kind of TOC for the API pages, but for larger screens only.
• So you'd really be adding this to screens where the menu is not visible, and mobile. I like the design.
• So the TOC menu should operate and display the dropdowns in the same way as the current menu does. So when you click it opens the sublinks.
• The current JS can likely be reused for that. It might be possible to just use the same menu or copy and rejig it - up to you. Seems unnecessary to rewrite this, unless that was part of the original issue.
• why only on api V4x? If it's a simple includes I see no reason not to add everywhere it's going to be used.
• As Sebastian says please remove all changes that are only formatting.

@bjohansebas, Thank for your kind suggestions. Now it is ready for review.

1. accessibility improvements removed: font size and line spacing removed.
2. removed 4x api menu data .yml file.

This button should be visible on smaller screens, around 800px, or when the layout actually breaks, not on 1200px screens.

It shouldn't create that element

Thank you @bjohansebas @chrisdel101
@bjohansebas removed observer api as you suggested.
@chrisdel101 I adapted to code logic in my recent commits please review it.
Let me know if we can do it more better.

I don't think we should display that button yet when scrolling, or we should integrate it better. At first glance, it's not clear what the button does after scrolling.

By the way, fix the conflicts.

An example of how it could be better integrated into the page
Close:

Open:

An example of how it could be better integrated into the page

I think you didn't check max-width=540px break point. small screen width integrated btn appears below header. This floating btn appears in between 540 to 800 wide screens on scroll. Actually I don't like that arrow, I am searching proper icon for this. Right now only btn title appears on the screen.

@chrisdel101 , layout redesign is not for placing side bar on right or left. We could do with old positioning used in css code just by changing position right value. Layout redesign happen because of the issue #1614 . Previously all components placed manually used positioning. So it gets hard to solve issue #1614 by using js. So I suggested @bjohansebas to redesign layout css using flexbox and removed positioning, unnecessary css classes. Now we can reuse all side bar html on all pages. This is main reason to redesign layout css not placing right or left. Placing right or left is teams choice. I prefer to think which side is more accessible? Who is user? How most of the user read? It is confusing and complex to think.

About our discussion, I am user of this site for years. I navigated on api pages by using ctrl+f🤣. I really got annoyed. I have tested api pages and are really handy with right sidebar menus. About blogs pages right sidebar are annoyingly hard to read because menus are long with line breaks and words spacing. On blogs pages we can put it on left just because they are navigating to another page. And it is standard position on most websites.

We must talk about what design we want? Then only we are able to integrate modern design. Now I did with minimalistic approach with existing styles and improved accessibility.

I prefer the left since I find if easier to read, think navigation pane in Word, and since it seems your functionality would work on either side, but I'm not requesting you change it. Seem Sebastian is okay with right side too and you had your reasons to put it on the right.

Yeah I used ctrl-f too. Hopefully this helps us not use that as much ha.

👋 @bjohansebas and @chrisdel101, Is it necessary to add underlines in sidebar menus? I prefer to add underlines only in docs because we need to distinguish links from the text content. And adding underlines or outlines on user interaction for sidebar menus.

Note: some documentation websites use underlines only on links(sidebar links blogs, middleware's) that are navigate to another page. And links that are navigating on same page don't use underlines (api pages, changelogs').

Now we are using standard design for sidebar menus, same page navigation menu's on right and another page navigation menus on left. I want know ur thoughts. Right now I keep underline and outline for testing. Which one should be removed?

Good question, I think we could remove the underline in the TOC.

some documentation websites use underlines only on links(sidebar links blogs, middleware's) that are navigate to another page. And links that are navigating on same page don't use underlines (api pages, changelogs').

That's a good idea, although I think we don't have any links pointing to other websites, at least in the menus.

@bjohansebas, TOC is ready to launch 🚀.

note : fixed #1807 because it is relevant to this pr.

Great, I will review it properly very soon.